CLAs look good, thanks!

re: additional label, I like "good first bug" --- it doesn't sound as low-value, it just sounds "doable"

Do we also want to ask the triager to decide whether this issue is:

1. actually something we want in angular (if not it should go into IceBox or be closed)
2. whether it has a breaking change (if not it can go into 1.3.x milestone)

@btford @caitp - this is not exactly how I've understood the conclusion from our discussion. I left the meeting with the impression that we want to have only one label to attract commiters and this label should be only put on issues that are relatively easy and quick to review. In exchange we commit to reviewing those in a next patch release (or immediately if a patch is small). In this sense 'good first bug' and 'PR plizz' should be one and the same label.

Once again, the reasoning here is that we want to attract people and give them a grantee that they work will be reviewed / merged pretty quickly.

my takeaway is that we want three things:

1. to indicate that an issue is considered "valid" (an accepted bug)
2. to indicate that the issue is being tackled by angular-core (an assigned bug)
3. to indicate that the issue is good for an outside contributor (a mentored bug)

@caitp I think that problem is that we were discussing multiple things. But at the end of the day we simply want to indicate to people issues that they can work on and grantee that we are going to review PRs fast (which implies that those issues / PRs need to be relatively small / simple). For this we just need one label.

Let's not make it more complex than necessary - there are already many PRs / issues with the 'Pr plizz' label that are not actionable / not being acted upon. So let's simplify it and make sure that we've got a simple system in place that makes people send PRs that we can merge quickly.

cleaning up the poorly maintained PRz plz items is a separate issue --- making it easy for people to contribute is accomplished with the mentored bugs thing, easy as pie

@caitp those are connected. We need to clean-up the current situation and put in place a simple workflow that prevents things from piling up in the future.

I would rather we have only one label - whether it is PRs Plz or Easy First Fix, I don't mind. But having both will lead to ambiguity for the triager and the potential PR submitter. If the PR is not easy then we probably shouldn't be advertising it for random people to attempt a PR.

This could work:

1. Good First Bug -> communicate that the community can/should fix this, is a mentored bug
2. In Progress -> communicate that core team is working on this, not a mentored bug

So, we would have 3 messages to the community:

• Good First Bug - please send a PR, we are going to review it quickly and merge if it is good
• no label - go ahead and send a PR but we can't guarantee that we will be super-reactive on PRs (although we are going to try our best)
• In Progress - bigger thing that someone from the core team is working on this, not the best candidate for a PR from the community

I think I like it. We can rename the PRs Plz to Good First Bug

I like this too - although I could be convinced that the choice of Milestone would indicate the the In Progress label - i.e. if it is in 1.3.7 then it is being dealt with by the core team - if it is in 1.3.x then it is not.

Should we also insist that triagers cannot attach either of these two labels until they have a team member who has agreed to be assigned (either as a mentor or to own the solution). Or is it only that we must have an assignee before it can be put in the 1.3.x milestone with the associated label?

I think that it is reasonable to assume that core team members can only self-assign themselves to indicate that their either working on an issue themselves or are ready to mentor / follow up on the issue.

Would again like to stress that although labels are helpful, best would be
to explain your intention long form in a comment when applying a label. I
think the ambiguity discussed here could largely be resolved if we do that.

On Wed, Dec 10, 2014, 12:15 Pawel Kozlowski [email protected]
wrote:

I think that it is reasonably to assume that core team members can only
self-assign themselves to indicate that their either working on an issue
themselves or are ready to mentor / follow up on the issue.

—
Reply to this email directly or view it on GitHub
#10375 (comment).

I am totally with you on that one @btford !!

@pkozlowski-opensource - my thought was that we still want triagers to attach this label but that we also need to have mentors that will follow it up. So I am suggesting that the triager must either self-assign or find someone who is willing to be assigned - and not just to assign someone without their permission :-)

@gkalpak - that would be awesome and hopefully once we have merged a couple of said "good first bugs" we would be contacting you to ask if you want to get more involved in further more complex bugs :-)

@petebacondarwin: Good point ! I didn't know that was the plan. (Sounds like a good plan btw.)

@btford - do you want to make a decision on the label issue and merge this in?